home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19981211-19990422
/
000023_news@newsmaster….columbia.edu _Fri Dec 18 11:41:29 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1999-04-21
|
3KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA27861
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 18 Dec 1998 11:41:28 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA28791
for kermit.misc@watsun; Fri, 18 Dec 1998 11:41:28 -0500 (EST)
Newsgroups: comp.protocols.kermit.misc
Path: news.columbia.edu!panix!cam-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.xcom.net!ix.netcom.com!gerlach
From: gerlach@netcom.com (Matthew H. Gerlach)
Subject: Re: receiving straight binary
Message-ID: <gerlachF46656.2yF@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <gerlachF4602I.IDE@netcom.com> <75dsph$4i1$1@apakabar.cc.columbia.edu>
Date: Fri, 18 Dec 1998 16:36:42 GMT
Lines: 51
Sender: gerlach@netcom15.netcom.com
Xref: news.columbia.edu comp.protocols.kermit.misc:9655
In article <75dsph$4i1$1@apakabar.cc.columbia.edu> fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
>In article <gerlachF4602I.IDE@netcom.com>,
>Matthew H. Gerlach <gerlach@netcom.com> wrote:
>: I have a device that spits out raw binary serial data, and I want it to go
>: to a harddrive. I'm using 6.1.193 Beta.05 on a Solaris machine. What I
>: did was write a small program that reads stdin and writes it to a file. I
>: then used the ckermit "redirect" command to run my program attaching the
>: serial input stream to my program's stdin.
>:
>: I'm sure there is a better way to do this, but I'm not sure what that better
>: way is. I have written scripts using the "input" command that does
>: the same thing for ascii text, but I'm not sure it would work too well
>: in the this case.
>:
>There's no reason why it shouldn't:
>
> set line /dev/tty0 ; or whatever
> set speed 19200 ; or whatever
> set parity none
> set flow rts/cts ; or none -- not xon/xoff
> set session-log binary
> set terminal byte 8
> set terminal character-set transparent
> log session
> input 9999 termination-sequence
> close session
>
>The trick is to know when to stop logging, but you must have had some
>criterion in your stdin/stdout program so you should be able to use the
>same one here.
>
>- Frank
The termination criteria is the trick. Currently, my stdin/stdout program
has no "stopping criteria". It stops when I signal it. From the "input"
command's point of view, the data stream is random; so there is no
pattern to "look for". I just want to "input" the bytes and log them.
For the record, the data stream is a Mu-law encoded audio stream.
Thinking about this more. What I have is a burst of data coming out of the
device. So a convenient script would wait a certain amount of time
for anything to come over the wire, log it, and when there is large pause
in the data stream, say a second or so, it would stop.
Looking at the "input" command in the manual some more, if I just give
it a timeout and no text it will wait for any single character. I suppose
this would work, but I'm running at 115k, and it seems "input"ing
single characters might be rather expensive processing-wise.
Matthew